perm filename ELEPHA[S89,JMC]2 blob sn#874506 filedate 1989-06-16 generic text, type C, neo UTF8
COMMENT āŠ—   VALID 00005 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	%elepha[s89,jmc]		Elephant 2000
C00006 00003	\section{Speech Acts aka Performatives}
C00013 00004	Notes:
C00018 00005	\smallskip\centerline{Copyright \copyright\ 1989\ by John McCarthy}
C00019 ENDMK
CāŠ—;
%elepha[s89,jmc]		Elephant 2000
\input memo.tex[let,jmc]
\rightline{\vbox{\it
  \hbox{I meant what I said, and I said what I meant.}
  \hbox{An elephant's faithful, one hundred percent!}}}
\medskip
\title{Elephant 2000: A Programming Language Based on Speech Acts}


	This paper is dedicated to the memory of a recent
insufficiently ambitious talk on Programming Languages of the
Year 2000.  There are two contentions.  First, speech acts
are appropriately understood as parts of procedures rather
than as logical sentences.  Second, abstract speech acts
are useful constructs in more advanced programming languages,
leading to programs with expressiveness closer to that of one
person instructing another.

	The Elephant 2000 programming language involves three ideas,
all of which are new.

	1. The language statements include performatives like
asking questions, making requests, answering questions, making
promises, making pronouncements that create facts (analogous
to a minister pronouncing two people man and wife)
and making internal commitments.  Also only parts
of the program ``authorized'' to perform certain actions do so.
The performatives have {\it speech act} semantics in that it
make sense to ask whether the program answered questions truthfully
or carried out its promises.

	2. Expressions of the language can refer to the entire
past.  This feature means that data structures need not be present
in Elephant 2000 programs.

	3. The statements include the resources of set theory, i.e.
the ability to refer to sets defined by properties.  Sets of times
are used often.

	These permit some absolute notions of correctness.  A correct
program answers questions truthfully and carries out its promises.
%
$$\eqalign{input(t,&request(reservation(flight,date,person)))\cr
&∧ card \{x|is\hbox{-}reservation(x,flight,t)\} < capacity(flight)\cr
⊃ output&(t,promise(reservation(flight,date,person))).\cr}$$

But what about consing up a seat assigment?

\noindent Remarks

1. The philosophical notion of speech act regards them as natural
kinds whose nature is to be discovered.  This paper treats speech
acts as something to be invented.  The question is what sorts of
speech acts are useful.  Naturally, contemplating human usage is
helpful in deciding what formalisms to introduce.

\section{Speech Acts aka Performatives}

	Linguists and philosophers of language have classified
and studied non-declarative sentences.  Linguistic attention is
drawn to some kinds of non-declarative sentences because they
have a different syntax from declarative sentences in the
grammars of natural languages.  These include questions and
imperative sentences.  Others, it has been pointed out, need to
be regarded as semantically (or pragmatically) non-declarative
even though they have declarative grammatical forms.  An example,
is the sentence, ``I now pronounce you man and wife''.  It isn't
just a statement of fact, because uttered by a suitable person
under suitable circumstances creates a state of marriage and
gives the two parties the rights and duties thereof.

	These sentences are sometimes called {\it performatives} or
and sometimes {\it speech acts}, so far as I understand
it, whether they are being studied syntactically or pragmatically.
The performatives include questions, commands, requests, ordinary assertions
promises and others like the above marriage example.  It seems to
me that the marriage example might be called a declarative if
the term hadn't been pre-empted.

	The Gaw of Speech Acts is the Berkeley philosopher
John Searle (19xx).  I don't know if he would approve of
what follows.

	As is usual in science and philosophy, speech acts have
been studied entirely (are there exceptions?) as natural
phenomena which are to be observed and characterized.  {\it What
kinds of speech acts are there, and what are their properties?}
As is common in engineering, mathematics and AI, we ask a
different question.  {\it What good are speech acts, and which
kinds should be designed for what purposes?}  Of course, these
studies will interact.

	Here's the idea.  Suppose we include in a programming
language a notion of {\it performative} and give them a distinguished
syntax that permits compilers, program transformers, and proof-checkers
to recognize the different kinds of performatives and parse their
structures.  We can then give these performatives a certain
``semantics'', where we mean semantics in the sense of programming
language semantics, which often corresponds with what linguists
would call pragmatics.  Once we have introduced this semantics
we get certain ``internal'' notions of correctness.  A
 {\it performatively correct} program answers questions
truthfully, carries out its promises, fulfills its commitments,
 obeys properly
authorized commands, obeys restrictions imposed on
its behavior by commands and by ``speech acts''
analogous to the act of marriage.

	The expected benefit of admitting speech acts in
programming languages or even  basing languages on
speech acts is the same as those claimed for other higher
level language constructs.  The programmer's intention
is more clearly represented in the program, the program
is easier to understand and to modify, and the notion
of its correctness is more definite and readily proved.
We also expect programs to be shorter.

	The present paper introduces two other innovations.
The first seems essential to take proper advantage of
including speech acts, and the second makes the programs
shorter.  In the preliminary version of Elephant 2000, we
will not worry about efficient compilability, or even about
compilability at all.  We concentrate on features that
permit the programmer to express what he wants the program
to do.

\section{Reference to the Past}

	
Notes:
How should our performatives differ from those of natural language?

1. Our performatives are abstract.  We define
promises without saying how they are to be expressed.  Later
we may choose one or more concrete representations.

What is a reservation?
	It is a commitment to let the passenger sit in a particular
seat on a particular flight.  Perhaps giving the passenger the
reservation consists of truthfully informing him that the system
has made this commitment.  Not quite.  Giving the passenger the
reservation also includes assuming a legal obligation not to
cancel the reservation except for an allowed reason.
Maybe we can regard assuming the legal obligation as an
internal act, and the external act consists in telling the
passenger truthfully that the obligation has been assumed.
Remember that the passenger will normally not know the exact
obligation that has been assumed.  This is another reason
for keeping the notion of reservation abstract.

request reservation(<flight>,<day>)


You may be looking for the phrase "An elephant's faithful one hundred
percent" which I believe is from Dr. Seuss's "Horton Hatches A Who".
Horton is an elephant who faithfully sits with (on?) a long-incubating
egg.


2. The program should {\it ask for} the information it needs.


3. People have asked whether Elephant is a programming language
or a form of specification.  It is a programming language in
that a compiler can generate a machine language program
from an Elephant program.  However, Elephant lacks a major
quality of ordinary progamming languages.  There is no longer
any guarantee that the program will function correctly.
This is because the process of compilation involves
nonmonotonic inference on the part of the compiler.
The compiler generates assumptions and the correctness
of the compiled program depends on the assumptions being
true.  The compiler will report the assumptions it made,
and if the user doesn't like them, he can say $maybe(not p)$,
in his next version forcing the compiler to generate code
that takes into account the new possibility.  For example,
the compiler will often assume that necessary information
is present.  If told that it might not be present, it will
generate a program that asks for it.

	One of the ideas that came from trying to invent
Elephant is that the above property may be inevitable in
trying to make programming languages that come closer to
the human ability to describe procedures and to describe
modifications to procedures.
\smallskip\centerline{Copyright \copyright\ 1989\ by John McCarthy}
\smallskip\noindent{This draft of ELEPHA[S89,JMC]\ TEXed on \jmcdate\ at \theTime}
%File originated on 10-Jun-89
\vfill\eject\end